Many companies use integrated circuits, e.g., secure microcontroller systems like smart card ICs, to deliver services to consumers. Examples are payment cards, payment tokens, public transport cards, Subscriber Identity Module (SIM) cards for mobile phones, health cards, etc.
Integrated circuits are often at the heart of commercial applications connected with large financial interest. The integrated circuit comprises confidential, proprietary information such as cryptographic keys, executable computer code, etc, stored in a memory of the integrated circuit. Examples include, banking applications wherein the integrated circuit is responsible for the authentication of money transfers and content distribution systems wherein the integrated circuit is responsible for restricting access to the content to subscribers to the distribution systems.
For example, content distribution may be done over a network comprising multiple set-top boxes. In each set-top box an integrated circuit, typically integrated in a smart card, comprises secret cryptographic keys and/or secret decrypting algorithms for decrypting content, e.g. music, movies, etc, and/or decrypting further cryptographic keys. Further cryptographic keys may include, for example, so-called Control Words (CW), Entitlement Control Messages (ECM) and Entitlement Management Messages (EMM). Further cryptographic keys may be used for increased security and regional control.
Naturally, the security of these integrated circuits is important. Persons who try to manipulate integrated circuits, in particular smart cards, or use information contained thereon in an illegal and/or unauthorized manner will be referred to as ‘attackers’. If an attacker manages to break the security of an integrated product he may be able to perform or initiate transactions for which he is not authorized.
Today those integrated circuits systems are typically application provider centric. This means that the product is defined and controlled by the application provider and that this entity is also the issuer of the hardware to provide a service, e.g. a smart card. Consider a banking card as an example. The issuing bank defines the product including the secure hardware, the operating system (software) as well as the application(s) being used. The source of all of the components is known to the issuer. Even though the bank did not manufacture the card himself he has selected all the components himself, and so has a reasonable basis for trusting the resulting integrated circuit.
However, as more and more services require a secure integrated circuit, in particular a smart card, to obtain access to the service, it becomes less viable to use a different smart card for each new application and/or service. Integrated circuits, in particular a smart cards, may be provided to a customer, which circuits are configured to receive an application after the circuit has been delivered to the customer.
Examples for such products are NFC enabled mobile phones or smart-cards configured for multiple applications. The hardware issuer of these devices is independent of the application provider. In particular, the application provider may not have selected the hardware manufacturer himself. The application provider may not even know who manufactured the integrated circuit. Even if the application provider is told who the manufacturer is, he does not know if the can trust this information. Typically, the application provider has no knowledge about the product details, such as hardware details of the circuit which has been provided by the hardware manufacturer.
For example, an application provider of some sort, e.g. a bank, a content provider, a loyalty program, etc, may download an application to an integrated circuit to enable that integrated circuit with new functionality. The new functionality allows the owner of the integrated circuit on which the application is installed access to new services, such as banking, content, and loyalty programs, respectively.
When a consumer wants a new service installed in his integrated circuit, he may contact a selected application provider. The application provider should enable the new service in the customer's integrated circuit. Before installing a new application on the integrated circuit, the application provider would like to know if the customer's integrated circuit is capable of running the new application. For security related services this may include ascertaining that the product is sufficiently secure.
Assuming there are a lot of companies providing products containing integrated circuits on which applications may be installed. The application provider will typically not trust them all. In particular, if the application which is to be installed is sensitive, security wise, he will be hesitant to install his application since he cannot manage the risk. Without installing the new application, the integrated circuit does not obtain access to the new service corresponding to it, and consequently the application provider is not able to provide the service to the customer.
Various risks are associated with installing an application on untrustworthy hardware. For example, an attacker may try to get an application provider to install his application on hardware which is under his control. In particular, on hardware that allows the attacker access to the installed application or even on hardware that allows the attacker to modify the installed application.
Although computer application code, like cryptographic algorithms which may be embedded in it, are typically designed to be robust and secure even when their content is revealed to an attacker, in practice it may be wise to make an effort to keep these assets secret. From the moment, a cryptographic algorithm such as an encryption, decryption, signing, verifying algorithm, etc, or computer code such as operating system code, device drivers, application code, access algorithms etc, are known to attackers they can start screening the algorithm or code for weaknesses. Cryptographic algorithms may allow cryptographic attacks which were not anticipated by the designer of the algorithms. Software code may comprise faults, also known as ‘bugs’, which can be exploited in order to obtain rights elevation. For example, once software code is available it can be screened for so-called ‘buffer overflow’ problems. A ‘buffer overflow’ problem arises when a temporary buffer is allocated with a smaller size than it is used. As a result, an attacker can use such a software fault to overwrite parts of the memory. Although programmers typically strive to avoid programming faults, such as buffer overflows, they are nevertheless known to happen.
Moreover, if an attacker also has the ability to modify the installed application he may be able to circumvent security measures in the application.
For example, if an attacker gains read access to an application for a loyalty program, he may find weaknesses which allow unauthorized increases in, e.g., an allotment of points that can be used for future purchases. If an attacker gains writing access to the application for the loyalty program, he may be able to increase the allotment of points directly.
As there are thousands of vendors of consumer products, such as mobile phones or PCs, and of smart cards, such as multiple application cards and white label cards, it is very hard for an application provider to verify if his application can run on the consumer products and if the application provider can trust the consumer product.
Problems such as these explain the slow uptake of multiple application smart cards in areas such as banking and content distribution.